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Within the 3rd Generation Partnership Project (3GPP), the thrust of the 
session initiation protocol (SIP)-based Internet protocol (IP) multimedia 
subsystem (IMS) is envisaged to aliov/ a swift progression towards the 
provision of multimedia applications for increasingly demanding end users. 
The paradigm of service programmability using open network application 
programming interfaces (APIs), with open service access (OSA) as its main 
exponent, is helping to drive this development together with the use of SIP, 
The focal point of this paper will be the multimedia services architecture in 
the IMS by providing details of the interaction of the IMS and the application 
servers in the form of the OSA gateway and the SiP application server. The 
paper aims to assess the value of the IMS service control (ISC) interface on 
application server interaction in the IMS. The paper will provide an OSA 
application use case, and will also present the presence server as an example 
of a SIP application server that fits in with the IMS. 
© 2003 Lucent Technologies Inc. 



(GSM) core network, i! has now turned Its attention cither he GPRS ox packet data network (PDN). As part 

to evolving the core network based on an Internet of the harmonization process between the Universal 

protocol (IP) backbone. In particular, as part ol one of Mobile Telecommunications Network (UMTS) and 

the 3 GPP releases, a ne w subsystem is being intro- CDMA2000* networks, the 3rd Generation Part- 

duced, referred to as the IP uswhimcdb subsystem nersinp Project 2 ( 3e . i ; itie equivalent standards 

(IMS) (•>]. The primary it of the IMS is die delivery partnership project t the task ol evolving code di- 

of an integrated voice and data infrastructure to sup- vision multiple access (CDMA! networks, a tins to tn- 
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Panel 1 , Abbreviations, Acronyms, and Terms 

3G — third generation 

3GPP — 3rd Generation Partnership Project 

3GPP2 — 3rd Generation Partnership Project 2 

APi application pro< < i 3 iterface 

B2BUA— back-to-back user agent 
CDMA2000*— 3G evolution of IS-95 standard 
CDMA — code division multiple access 
CF — call forwarding 
CPL — Call Processing Language 
CSCF — call session control function 
GGSN— gateway GPRS support node 
GMLC-— gateway mobile location center 
GPRS — General Packet Radio Service 
GSM — Global Systems for Mobile 

Communications 
HSS — home subscriber server 
l-CSCF— interrogating CSCF 
ID — identification 

IETF internet Engineering Task Force 

IMS! — international Mobile Subscriber Identity 

IMS— iP multimedia subsystem 

!P — internet protocol 

iSC— IMS service control 

ISDN — integrated services digital network 

ISUP— ISDN signaling user part 

MRFC— media resource function controller 

MRFP — media resource function processor 

OSA — open service access 

P-CSCF— proxy CSCF 

PDN packet data network 

PSTN public -switched telephone network 

S-CSCF serving CSCF 

SDP — session description protocol 
5GSN — serving GPRS support node 
SIMPLE — SiP for instant messaging and 

presence leveraging 
S!M — subscriber identity module 
SIP — session initiation protocol 
UE — user equipment 

UMTS — Universal Mo < lunications 

System 

URI — uniform resource identifier 
URL — uniform resource locator 
WLAN — wireless local area network 



The overlay architecture will evolve in future releases 
to support access 1 . such that subscribers 

maj access f e s ysiemibrou « tea ich 
as a wireles local area neiwot V> \" cornier >n 
or a fixed wireline connection. Tins is subject to ad- 
ditional work chiciiy it! the area oi authentication of 
the end user without 3 UMTS subscriber idenbii ca- 
tion module (SIM). 

The IMS aims to bring about the union oi the 
Internet and the wireless environment. This synergy 
would allow for communications with multiple ses- 
sions, where mixed media can be used pcrson-to- 
person or persoii-io-inaeliiue, and where media can 
bo e m 1 11 ii 1 1 t >. i The \ cc n 
is that this powcrfui mix oi capabilities will allow lor 
new and richer services than citrreittiy available in the 
wireless environment From an end -user perspective, 

ing for adoption oi a personalized tiles;; ic. r-or exam- 

and intuitive identifier (not a telephone number, but 
an operator-administered uniform resource identifier 
(URI), such as myAddress@MobileProvider.com), a 
user may be reachable through multiple communica- 
tions forms such as voice, e-mail, video, or instant 
messaging using a single communications device. 

The IMS introduces a multimedia call control 
model [4] based on the session initiation protocol 
(SIP) defined by the Internet Engineering Task Force 
(IETF) [8|. New network elements are introduced as 
part of this subsystem that arc associated with the ses- 
sion establishment, control, and tear down. These 
nodes are generally referred to as call session control 
functions (CSCF) and several variants exist depending 
on tire roles they piovide. They maintain state inior- 
mation for the duration of the session. In order to 
allow inlcrworkiug with oilier networks, such as the 
existing public-switched telephone network (PSTN), 
• unaum. and media si.itew.iyN are introduced as 
well. Additionally media resource hind ions are in- 
troduced to support conferencing and announcement 
capabilities. 

Aim \> d. iU.>. i (-a . i.ie iU. 1 j. i! 
for muithmail 3 .enm cin I'a 'bete. mm' rich 'V\ e ■ 
anticipated by the end user will be provided by a 



separate sendees layer. This sendees layer can be de- 
scribed briefly as a collec tion ol application servers thai 
lis 1 be m 1 > ord dc main or 

can exist outside the operator's traditional domain. In 
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Figure 1. 

IMS overlay architecture c< 



the latter case, the service provider and t he operator 
enter a commercial agreement to provide services. A 
recent report commissioned by the UMTS iortim f! 1] 
estimates Ihai I he revenue (row third -gencraiion .ser- 
vices is expeeted to he it) lite region oi S>22 billion in 
the next eight or so years. Any service that enhances 
the user's experience is likely to generate some rev- 
enue. There is no space lot complacency. Services will 
have to be dynamic to meet customer's very high 
expectations, and a higher sendee churn is expected. 

I is 11 1 1 i " > v -> 1 i 

chitecture that accompanies the IMS. Within 3 GPP, 
three sets ol standardized platforms for service con- 
lightweight SIP- based support. This paper will locus 
on what are generally considered the two primary 



mechanisms lor interaction between the IMS and the 
application service layer, in the form of the open ser- 
vice access (OSA; gateway and the SIP application 
server. First, the paper will provide an overview of the 
IMS arid the new network elements that are intro- 
duced. Next, some of the new procedures and 
processes required to support services in the IMS are 
presented. When the stage is set, the IMS service ar- 
chitecture will be introduced, along with an overview 
of the various service control scenarios. Tins discus- 
sion will be augmented with examples of the two ap- 
plication servers oi interest, the OSA gateway and the 
SIP application server. To illustrate the interactions for 
service control, the -presence service is used as an ex- 
ample in this paper, where we outline how IMS sup- 
ports presence and how the architecture supports a 
presence- enabled service. 
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0"<::-v;v.v sUte MS 

■Iris section -a lip o\ It- o b iei >vert ew , 1 1 ^e 
IMS. A detailed overview of the IMS architecture is 
provided in [7]. Figure 2 shows the high-level IMS 
architecture and the relation hip to the underlying 
packet-switched domain and radio tccess. Although 
the figure shows underlying 3 GPP GPRS and UMTS 
radio access jrdiiio. una, the same IMS high-level 
at Inn. iiiu aist » 'i r ' ^ there is 5(iJ'P2 n" 1 
lying architecture. 

Frgnn J and the toli.nyuie des.npn >n ol th 1M-- 
arc simplified to highlight aspects thai are important 
for understanding how sendees are provided. 

The IMS employs the concept of home control 
architecture, so that no matter whether a subscriber 



is in the home network or in a visited network, the 
subscriber's services n >. es t 1 1 li i 

etwori 1 his wa ubsc ees 1 he saint 

subscribed neit and subscribed service behavior 
at all times, regardless oi where the subscriber is 
roaming. The three call session control function 
types shew i o Figure tbli it control. The 
proxy CSCF (P-CSCF) is the contact point into the 
IMS lot the user equipment (UES and may be in a 
visited network. The interrogating CSCE (l-cSCr't 
is the contact point into the UE's home network 
horn oilier jict works The serving CSCb {S-CSCD is 
the Sib session control point fur the UE and is 
always located in tiic UE's home network, in the 
IMS model the S-CSCF does not contain service 




CSCF —Call session control function 

tf. or tni , 1 j •■ . r -a .. S 

GsRAN-.GeM T F , assess 
GG.SN te .PRS support t Kie 
GPRS— General Packet Radio Service 
GSM-Giobai System fot Mobile Coninunications 
r-iSS — Home sabso seer sei se: 



i CSCF —Interrogating CSCF 

IMS— -iP multim lia i 

IP— Internet protocol 

P-CSCF — Proxy CSCF 

SGSN— Serving GPRS support node 

UMTS— -Universal Mobile Teiecommuoications System 

U7RAN — UMTS terrestrial rasiio assess network 



Figure 2. 

IMS high-level architecture o 



a GPRS network. 
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: logic is provided by the applic; 



The home subscri r server ;HS 1 is subsa let 
and service-related dai.a. The I-CSCF accesses the KSS 
to determine ai no e s i w est j e 

lite S-CSCF accesses it in order to be able to enlist ap- 
propriate application servers to provide services to the 

Sill 

get user profile and subscr ipt iv^j; information. 

An application server may need to access IMS 
network media resources, sac;; as an announcement 
facility. The IMS architcci are isolates these 
from tin out ■ In having tin ppikatio 



.s lMf 



icdia 



apt' 



>thr 



Addressing in MS 

As part of the IMS, a new addressing space is in- 
troduced thai it n^ -t „ u 'cess. Air LMS 
snbsv ribcr is v huracicri/cd t>\ a shigle t ivatc identity 
but may have set alpubli ser ideutiltes The private 
-user identity is a unique global identity (akin to the 
international mobile subscriber identity [IMSI] in 
GSM) associated with a user's subscription, and is pre- 
dominantly iised to uniquely identify a user irons a 
network perspective. Private identities are assigned 
by the home network operator and are typically used 
for registration requests and authentication. Public 
user identities are a more human readable form of 
communica tions addresses that arc used by any user 
requesting communication Willi other users. The 
addressing scheme adopted allows for normal 
telecommunications numbering in the form of a 



gateway are employed when the session involves a 
call to or from the PSTN or a legacy mobile network. 
The media gateway provides the bearer path between 
the packet-switched and the circuit-switched envi- 
ronments and may also provide media resources. The 
media gateway control function controls the media 
gateway ana also .does protocol conversion between 
SIP and ISDN signaling user part (TSUP). 

The CSCFs, media gatcwa\ and media resource 
control functions, and application servers ail use SIP- 
based signaling among themselves. Of particular 
interest is the SIP-based service control interface 
referred to as the IMS service control interface 
between the S-CM.'F and the application server. 

Procedures ami PnKessswj m the IMS 

The following subsections go into more detail 
about sen ice-related aspects 1 " md about how 



. and new processing in the 



r lot 



ed r 



e IMS, : 



IMS ate discussed. 



tion needs 10 take place lot each public user identity. 
The registration is a moons ol associating a user with 
an S-CSCF and allows the delivery of subscriber ser- 
vices according to hie public user identity being itsed. 
It is possible to register multiple public identities, 
i si, n i k in i .aid u 

i w i m! u K i l 1 1 u , 

process are covered in the next section. 



Registration Process it! IMS 

In t >v t i ( t j t ^.etve any ntttb 

timedii sissii-n m the IMS, the usei needs to register 
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AS -Appi tendon server 

•-^----Morris subscriber server 
i-CSCf— Interrogating CSCF 
IMS — IP multimedia subsystem 
IP — Internet protocol 
P-CSCF -Proxy C'iCF 
S-CSCF— Serving CSCP 



independently from registration at lire radio access 
side wish the un-e rhr; e )in network. The 
IMS registration process may be user- originated or 
automatically triggered from the user's terminal. 
However, evpi da . m a . n !>■ Jd be a process 
initiated on "power on" alter success! u I attachment to 
a packet -switched domain (e.g., the GPRS network). 

The registration cc s ec h the alloca- 
tion of a serving C.bCF to a public riser identity. The 
allocation of the S-CSCF is dynamic, based on several 
factors, such as the load on the CSCFs in the network 
or the services that a user wishes to access, as implied 
by a particular public identity. 

The details of the registration process are de- 
scribed it: I"'; figure 3 provides an overview of the 
process, where a user sends a SIP REGISTER message 
(flow 3) to a P-CSCF, which may be in the home or 
visited network. The P-CSCF forwards this message 
to the I-CSCF of the user's home network (flow 2), 
since the private identity of the user provides this in- 

the registration process within the S-CSCF, the HSS is 
queried for the user's profile (flow 5), which includes 
the set of initial filter criteria giving information about 
the application servers that need to be involved 
for the user, under which circumstances each gets in- 
volved, and I lie relative priorities. Filter criteria are 
explained in the next section. The S-CSCF sends a 
third-party register request to each application server 
(flow 6) dictated by the filter criteria, and the appli- 
cation server can then get additional application 
server-specific or scrvicc-spcciiic data horn the libs 
(such as privacy inlorination), ii needed tiiow 7). 

Filtering Criteria and the IMS Service Control Interface 

The S-CSCF rises biter criteria to involve the ap- 
: - i ; - an >u servers as needed to pi., vide services to sub- 
scribers. The bltcrmg r done on MP request messages 
ttch isREGI ii IN S BS or BYE but 

no i [iv i I r nst t k i . i hi 

a varied, of crit-n'n sir n as the m-nlmd,.; -, CPrequea 
oil v herder the request is received in the originating or 
terminating case, on whether a particular media type is 



Figure 3, 

IMS registration service, 

included in die session description protocol (S1)P; of a 
request, or on the presence or content of a particular 
SIP header. 

A specific user may get services from more than 
one application server. When a SIP request for a dia- 
log comes in, the highest priority filter criteria are 
considered by the S-CSCF first, and, if the SIP request 
is selected by the criteria, it is passed as is on to the 
application server cerrospoiibiry; to the highest pri- 
ority filter criteria The application server perforins 
service logic, may modify the SIP request, and may- 
send the request bac k to the S-CSCF The request that 

- >t e t r k tti e" 1 is it t-i ed 

to the next highest priority ii Iter criteria and, if it sat- 
isfies these criteria, ir is the input to the corresponding 
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until ai! the different priorities of filler criteria are con- 
sidered or until l he ervio logic performed. ;;■ ont of 
the application servers results in a final response io 
the SIP request. Cine u ■• contacted an ap; it' an >u 
server can choose io remain in the signaling path or 
can remove itself front the path for subsequent 
requests depending on v, u ru^cs tin user is using 
(or is eligible to use). 

An application server can play the role oi user 
agent, of redirect server, of proxy server, or it may 

c ll{ lo, I t 1 1 S 1 Ij ^ I p 

the application server provides a platform thai en- 
ables a variety of services. The S-CSCF adds an iden- 

if the application server has performed third-party call 
control and thus changed the dialog identification. 

Flexibility to meet end-user needs is a hallmark, of 
the IMS. The filtering criteria tailor which service plat- 




to enhance subscriber satisfaction. The IMS service 
control (ISC) interlace to the application server, 
because it is based on SIP, does no! lock in predefined 
services. Instead, SIP and thus ISC provide primitives 
from which to build a variety of sendees. 

Sendee Domain 

The introduction of the IMS, the pieces- of regis- 
tering a public user identity, and the concept of filter- 
ing criteria were presented in the previous section. 
This section will elaborate on the application of the 
filtering criteria to invoke service interaction. The 
S-CSCF does not provide any services io the end user 
as il relies on the application server to provide end 
user services. 

One hey aspec t of rise dynamic sendee market is io 
have in place at an early stage a service architecture 
that is flexible, future proof, and allows a great deal 
of operator differentiation. This service architecture 



vices as well as third-party access, both in the trusted 
domain (having a very dose relationship with the 
operator) and in the tin trusted domain, where security 
ttre Irani m; have to he put in place by the operator to 
control or limit access to the network. 

The sendee arc hiioO it re defined in the fads ailows 
for three types of application platforms as identified in 
[6]. Each of these types addresses a particular need 
for various service deployment scenarios. First, there 
is the drive for rapid application development and 
third-parp, provisioning introduced hy the concept ol 
open network application programming interfaces 
(APIs) such as OSA and Parlay. Second, the increased 
usage of Internet protocols and concepts in the UMTS 
architecture allows for more lightweight, siP-hased 
mechanisms for service control. An example is SIP 




the OSA gateway and the SIP application server. 



Application Servers in the IMS 

Figure 4 shows how the IMS application servers 
an. represented by the SIP application server and the 
OSA gateway. Both support the ISC interface 
to the S-CSCF and a Diameter interface to the HSS. 
The S-CSCF treats these as generic application 
servers making sso distinction between the two. The 
filtering criteria determine the application servers in- 
voked to deliver services for a particular subscriber. 
The SIP application server can be any SIP-based 
application server that supports the required inter- 
faces. The OSA gateway is described further it! the 
hah wing section. 

Overview of OSA 

Within sOPl; osa is generally considered the 
service platform of choice for third -party application 
creation and deployment. OSA defines a set of APIs 
thai allows third-parry independent software vendors 
to use core network service capabilities as building 
blocks to create applications. For a more elaborate 
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OSA- -Open seisin; w. 
SIP— Session initiation 



Figure 4. 

Applxatmn servers in the IMS. 

introduction to OSA, the reader is referred to the 
3GPP specification [2] or to recent papers on the sub- 
ject [10, 12], Within the IMS, access to OSA is offered 
through a gateway, which is seen as a special case of 
a SIP application server. This OSA gateway commu- 
nicates with a S-CSCF through ISC, while offering an 
OSA API to applications. 

Within the IMS, it is possible to categorize the 
mechanisms for service interaction into three broad 
categories, as listed below and as illustrated in Figure 5, 
regardless of the type of application platform. 

* S N 

l 1 ' 1 I , n h it 1 ] ti 

■hit. nni icicvomnismkvnions systems, where any 
session origiiuui d hy a tiser. or a session tersm- 
nating to a user, could be subject to service con- 
in >i \.) . xmnpi'- - i >ii.. in inng stssn n k , .jitny is 
a prepaid service in which the application sewer 
session ft g, duration Musi uyun ; 




Scenario (b) 
Session initiated by ai 
application server 




a type of media! and terminates the session pre- 
maturely when the user runs out of credit. Session 
redirection Is a prime example for a terminating 
session, where an incoming session is redirected to 
a different user based on predetermined settings of 
the user. Scenario (a) in Figure 5 shows how a 

ii ' 1 -llllil.il'. d '. 'I"!! 1 Sii' iW'i 1 [ , J ;t , 

f e luwiiiwd n> lh' 1 p.r i.\ .11 ' w : 

>y\ . ws< ' wrier a -wwa" sws/ew .a .? This 
it. s lh t ere an appli- 

cation server iisiiiaies a session directly to a user 
(see scenario (hj in Figure 5). An example of 
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this mechanism is a conference service that 
invites pre-determined conferees to join a video- 
conference. 

This possibility covers the category where a user 
initiates a session or an association directly to an 
application street (sec scenario <ci in Figure 5). 
An example tit this mechanism is where a user 
requests access to presence information or a user 
requests the streaming of a new video clip. 

W Mtimedia Service Example 

This section describes a new IP multimedia ser- 
vice, while illustrating and highlighting control 
aspects of the IMS service architecture. The specific 
service chosen uses presence as one of its enabiers. 
hetore describing t he service it soil, a discussion will 
first be presented on tire presence concept and the 
architecture being defined in 3GPP for presence 
within the IMS. 
Presence Overview 

Presence provides the ability to know that a friend 
or colleague is "on-line* ana facilitates the sending 
and receiving of messages more or less instanta- 
neously. Unlike e-mail, an originating user knows that 
the destination user has received the message the mo- 
ment the "send" button is pressed. This gives the abil- 
ity for an electronic exchange of messages to take 
place in real time. This electronic dialogue can take 
many forms, such as text messages, images, files, or 
video clips. In order for one to be able to determine 
that other users are on-line in a non-intrusive man- 
ner, a mechanism to advertise this status is required 
together with the ability for other users to use this 
status information. In theory, this is a simple process 
where a u ; pnbiiehi - a- u mit information pen lin- 
ing t his/her status The t of b n it n 
ma lion is referred to as pnvtu'. and the associated 
informationi wlbrtf wt. • i • t 

formation is dynamic information about the subscriber 
or any entity thai has observable, variable attributes, 
studi as the user's present location or disposition to 
communicate. JGPP is currently standardizing a pres- 
ence sendee capability with the requirements defined 
in [3], 



Presence entities. As in the IETF, 3 GPP has 
adopted the term prcsi-nuly (from presence entity} to 
describe an entity that publisher, presence informa- 
tion. Generally, a p resent) ty is associated with a 3 GPP 
subscriber, but can be associated with a more abstract 
entity, such as a weather station. A centralized net- 
work node known as a presence server may distribute 
this information to interested parties. A consumer of 
presence information is described as a watcher. A 
ird) teanapt i lion res ing in an applica- 
tion server or in a user's mobile terminal. Watchers 
watch presentities, under trie restrictions imposed by 
lite privacy rules determined by the latter. The inter- 
ested reader is referred to [9] for more information on 
the IETF work on SIP tor instant messaging and pres- 
ence leveraging (SIMPLE). 

Presence architecture within the IMS. An overview 
of the 3GPP presence service architecture is shown in 
Figure 6, where oniy support within the IMS is 

server, which collects ana; distributes presence infor- 
mation. In reality, one would anticipate that there 
would be multiple presence servers for easier man- 
agement and load sharing. The presence server is con- 
sidered a SIP application server in the general IMS 
architecture, where it communicates with S-CSCFs 
through the ISC interlace. Potentially, presence in- 
formation may be supplied by network nodes (such as 
the S-CSCF) as well as by direct user input. 3 GPP 
introduces the concept of a network presence agent in 
order to convert network presence information into a 
uniform protocol (SIP) to the presence server. 

5GPP introduces the concept of watcher presence 
proxy and presenthy presence proxy providing ad- 
dress resolution, routine;, identification ol the correct 
network of the presence server associated with pre- 
• mm,, accounting, and huerworkmg with external 
or noncompiiant networks However, ail functionality 
ill th i xi 1 1 j c \ 111 t 

i provided !y combinations of the P-CSCF/I-CSCF/ 
S-CSCF. as shown in Figure 6. Tnterworking functions 
can be provided by a dedicated application server, but 

Presence messages arid call flows. To amplify the 
strength of the IMS service architecture and the ISC 
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in terface, I Iris section shows two service examples 
built on the presence service. The examples make use 
of call i[i he pro l > i > I 

torn. The two examples are based on the two types of 
application servers of interest., i.e., die SIP application 
server and the OSA gateway. Although the difference 
goes beyond the choice lor application server, these 
examples will demonstrate that the architecture and 
p ; micrlao: i m cm c ptl support i A II I 1 i 
w.miv; ippK iu. •!-. :^ subnq m Arl wan lv s d e. p:^s- 
ence information ol a presentity on 1 he end user's 
thai! For evn b t lhation an be an instant 
messaging buddy list, hi the OSA application server 
case. 1 cher is a linrd-j OSA applic 

The watcher monitors presence information on behalf 
of ail subscribers to the OSA application. The applica- 
tion could be a conference scheduler, e g., whenever 



a session initiation tripper is received, the application 
will check the availability ol ail conferees and set up 
the oebcrciKc a >idineh\ figure 7 shows how a 
SIP- based watcher application located in a user's ter- 
minal (labeled UE) may request to receive presence 
information about another user (flow 1). S-CSCF(l) 
represents the S-CSCF with which the watcher is reg- 
istered, while S-CSCF(2) is the S-CSCF with which 
the user being watched is registered. 

Potentially, S-CSCF(l) and S-CSCFI2) maybe 
located in different networks. The UB's (i.e., the 
watcher's; initial request to be notified of presence 
information for a specific presetrtity (Uow J ! is received 
at the P-CSCF, as it is the UE's contact point into the 
IMS. The P-CSCF relays the request to the S-CSCF 
to which the UE is registered, i.e.. S-CSCF(l). In 
turn, S-CSCF(l) forwards the request to the contact 
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point into the prcscnlity's network, i.e., the I-CSCE 
The I-CSCF will interrogate the 115 S to obtain the 
address of the S-CSCF with which the prcscntity is reg- 
istered (flows 4 and 5). Once this address is obtained, 
the I-CSCF can forward the request to S-CSCF(2). 
Suue S-t;S0F{2> does ma perform any service logic 
itseil, i vised on ds idler criterio, the watcher's request 
is forwarded to the presence server (flow 7y 
Subsequently, the present server edit t i o< e P 
the request tor notification of presence information. 
On the return path for the acknowledgement, 
S-CSCF(2) cars bypass the I-CSCF { Slow 9), since in this 
case, the routing iolonuatioii to the S-CSCF(l) has 
been included in tiie request t>y S-CSCF(I) (flow 3). 
The acknowledgement is passed through the P-CSCF 



back to the SIP- based watcher application in the UE. 
Once the presence information lor the presentity has 
been collected, or a change in the presence information 
has occurred, the presence server will send the infor- 
mation to the UE, through the S-CSCF12), S-CSCF(l), 
and P-CSCF (flows 12 to 15). The UE will acknowl- 

al.S r . < .-ipi , • ! lias imim U .! : i ,S !. i :i:' picsencc 

server {flows J ft u> 19). There are no flows to show 
bow i ! i updaxt - tht presence server will) presence 
information. At the time of writing, IETF and 3 GPP 
bad not agreed on a standardized mechanism as to bow 



this 



achieved 
Figure S si 



c r , ci - , i >v 1 sou ' tin s * s< ■ 
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APL — Application i-CSCF Interrogating CSCF 

CSCF— -Gil! session control function OSA — Open service access 

HSS— Home subscriber service S-CSCF — Serving CSCF 



that the OS A gateway has access to, and is independ- 
ent of any registered users. As in the previous exam- 
pie, mm! [in t s i" I , the 
liver being watched is registered. The ibird-pany OSA 
application is not a S1J' application. Instead, it com- 
municates through the OSA API interface with the 
OSA gateway, which, in lute with the IMS service ar- 
chitecture, is a SIP server. The third-party OSA appli- 
cation acts as a watcher. As a result, she OSA API 
methods need to be mapped onto the SIP requests 
and vice versa. The OSA gateway performs this func- 
tionality, as is described it! [12]. Tiie OSA API method 
. ih.-o 1 1 ail ■ >e, s j>n ■ )- a client applica- 
tion to register its interest in a certain presence-related 



event. An example oi an event could be a change in 
presence information for a certain subscriber on an 
end user's buddy list. The < )SA API method ewnlNotify 
(flow 14) will report the occurrence of the event in 
the network up to the third-parly OSA application. 
Details of the OSA API lor presence can be found in 
ph. Once the OSA gateway has mapped She OSA 
watcher rcquesi ilhiw 1 ! omo a MP watcher request 
(lUiwei, the request is iorwarded to the s-CSt ly i i to 
which ibe OS V gateway has access Entirely in line 
with the IMS architecture, S-CSCF(l) forwards the 
request 1o the contact point into the presentity's net- 
work, i.e., the I-CSCF (flow 3). From this point on- 
ward, the call flow is exactly the same as the one for 
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the SIP-based watcher application. Once the OSA 
gateway receives the notification from the presence 
server (flow 13). this needs to he mapped onto the 
cwniNoiity method. 

These call flows presented two quite distinct ser- 
vice examples, i.e., a SIP- based watcher application 
residing on a UE on dedal; of a stogie subscriber and 
a ihird -party < >SA -based watshcr application residing 

1 s ib [ t l si i 

domu n en dehali oi a tii i set [ subscribers. 
Nonetheless, the architecture and call flows support 

t i i t s i i ii < i ii i i 

In iact iron, the perspective oi the LVw network 
elements, both examples, although supporting com- 
pletely different business and deployment models, 



tide:- 



.ads 



With presence i ti call i i n can 
be enhanced in a variety of ways. The following 
illustrates some of ifiose ways. Let us say that 
the called party is present and available as 
s c thin \ I iec ^H^ 
com. n although both public < n !i a m (IDs) 
map to the same private > (or handset), I base calls to 
MyHomeo? ITSP.com can be forwarded to a message 
center. In this way all public IDs can automatically 
register with the IMS at power-up of the physical 
handset, bui sail management oi these multiple IDs is 
still possible by the end user. 

Now, let us say the called party is present but un- 
available and 'grumpy.' This presence information 
cat), be provided to the calling party prior to being 



dditi 



Description of a Presence-Enabled 



idem 



uidio. 



tal c 



takit 



, New 



I be 



ture may also provide end users with presence infor- 
mation of other end users tor entities), as with the 
instant messaging service. Alternatively, presence in- 
formation may be used to provide other enhanced 
services. In other words, presence information may 
be made available K> application screws as weii as 10 
end users. The sendee to be described here is such a 
service. 

This service example is a presence-enhanced call- 
1 rwat fin it > ^ , I , \ 
makes rerouting decisions based on criteria such as 
lime of day, day oi rue week, immediate, busy, and no 
answer. The rerouted target endpoim cat; be another 
phone number or a message center. Depending on 
the media rypr i >d ' ■< v t es. 



ler beit 
video ■ 



ittld b 



or unified 



.aiie 



i die 



used by the IMS in making routing derisions for a 
cab as an alternative or enhancement to the SIP se- 
rial and parallel iorbmg icaiitrcs. Willi presence data, 
lilei b lay b educed i o ne 

scenarios. 

SMS artd Service Architecture Walk-Through 

The call flow in Figure 9 details the messaging 
through the IMS and presence arciww.turc used in 
providing the prcscncc-cn ii.am.ed call forwarding 
service. In this scenario, the application server with 
e call lorw.at ire i e wa cher It sub cribes 

to the presence server lor presence information oh he 
UE subscriber (preset) thy). When a presence event 
occurs, such as when the UE subscriber updates 
i est- in t i n >T F5t t' se it to th 
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[Tcscf] 



CSCFj | CF AS | 



,-.rty UNAVAILABLE & GRUMPY) 



16. S!P INVITE 



III mi \ . 



Figure 9. 

Presence service example, 



pie, tlx L m \l 1 [ i i t u 
as "present but unavailable and grumpy." The CF ap- 
plication server, in turn updates it ubscriber profile 
records appropriately. 



When a call come? in lor the UTJ subscriber (steps 
2-9), the S-CSCF concludes thai it needs to forward 
the SIP INVITE to the CF application server based 
on filter criteria that it retric i fit '1 e HSS The 
CF application server reviews its stored presence 
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sioned actions map the presence status of "present 
but unavailable and grumpj K • 'b •nvat& calling party 
to message center Pa ^d ' ^ i\ it tie ci 

application server fonvards die calling parly :o the 
UE subscriber's message center. The CF application 
server acts as a back-to-back user agent (B2BUA) [S] 
in setting up this session, steps 13-19+. 

The CF application server also notes thai the UU 
subscriber gives permission tor calling parties to get 
his/her presence status. Therefore, the CF application 
server sends back to the calling party, the UE sub- 
scriber's presence mSo (sicrH Hi rbc preseiKi iulo i 
not supplied in the SIP NOTIFY message, as was de- 
scribed in Figures 7 and 8, since in this scenario the 
calling party does not act as a watcher. For the sake of 

response messages, e.g., rite 200 OK alter the NOTIFY. 



COfSCiM 



identity, the 
well as non- 



s nape 



e ha 



interaction of the IMS and the application sen ess in 
the form of OS A gateways and SIP application servers. 
One key aspect of the architecture is that the ISC 
interface allows the network nodes in the IMS to be 
able to interact with different types of application 
servers in a uniform manner, The example of a 
presence-enhanced sai.i-ionvarding service provided 
in the paper has demonstrated the flexibility <>1 the 
IMS service an biicUure. This flexibility is key ;o the 
successful deployment ol EVP-. 

"Trademarks 

CDMA2W0O is a trademark of the Telecomimmitadons 
Industry Association. 
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